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ABCTRACT 



A system for facilitating commercial transactions, between 
a plurality of customers and at least one supplier of items 
over a computer driven network capable of providing com- 
munications between the supplier and at least one customer 
site associated with each customer. Each site includes an 
associated display and an input device through which the 
customer can input information into the system. At least one 
supplier is presented on the display for selection by the 
customer using the ii^iut device. Similarly items from a 
supplier can be displayed for the customer to observe. 
Associated with a supplier of such items is an item database 
including information on presented items. Pcidng subsystem 
receives infonnation from the item database to determine the 
cost associated with a presented item. In addition a customo- 
information database stores information relating to the cus- 

Ullii tjUlJlur 'JifL'[^'V' ' 1 " M 1 1 irrt The customer monitoring 
< ^^gfaL ai gF^^^i^j ?y^^^fe'^ ^ t relating to that 

customer, ' ^ ffiht ! Mf H**"'^*"'^*'''^ ^f ' ^ hftrtgns^ m ' ^l nfn i . magdj| 

tx f>p_HnivihQiK 5iaiidtwligtfftBeycasiomS^ The 
customer monitoring object is configured to operate by 
responding to customer enquiries regarding a presented item 
by retrieving information relating to the item and presenting 
the information to the customer, receiving a customer's 
selection of a presented item; receiving customer 
communications, indicating a desire to receive die item; and 
passing a communication to initiate the delivery of the item 
to the customer. 

49 Claims, 15 Drawing Sheets 
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COMPUTER SYSTEM AND METHOD FOR such as simultaneously offaing a multitude of price 

ELECTRONIC COMMERCE discounts, perfoiming targeted advertising, or collecting 

sales feedback. 

BACKGROUND Another company, Open Market, is developing a similar 

1. Technical Field 5 electronic catalog system consisting <tf a HypoText Markup 
Tliis invention relates to a system for conducting inter- Language (HTML) authoring tool (called Sto-ebuilder), and 

active electronic commerce among a piuraHty of a server (called Webserver) connected to an integrated 
participants, and more particularly to a computer architec- back-end cormncrcc system (called IVansactionLink). This 
turecomprisingafamily of distributed, interface-compatible system appears to share similar characteristics and disad- 
commerce subsystems, where eadi electronic stare operates vantages as the Netscape system, 
selects a particular combination of subsystem iiiq}lementa- Thus, existing computer architectures for on-line elec- 
tions to meet store specific operating needs. tronic commerce are service providCT-spedfic ardiitectures 

2. Background platform-limited (the Internet) and require confor- 
It is desirable to provide a system and method for con- * ^f*^ ^^^^ specified subsystem 

ducting commerce via an electronic means, such as a com- ^l^taUons Such closed architectures may ^eatly 

puta- network, cable television network, or direct dial limt then: expandabihty or widespread aca^ 

modem. Previous attempts to ^ovide electronic commerce widespread acceptance oa^urs, this is lil^ly to 

subsystems have been custom tailored to an individual ov^anuinber of competmg systems, whose la J of interq>. 

commerce offering, and have not been adaptable to be able erability may force customers to log on to different archi- 

to provide a versatile system capable of supporting a wide '° lectures for different transactions or force vendors to m^- 

range of providers of goods and services. ^ equivalent operations on different architectures. Such 

° . . , . L J ^ J architectures are aimed at a customer-retailer level of 

To meet to need, several coinpames have developed ^ ^.ey do not support the 

cx>iEputei ardutectares for onhne dedionic catalog sales i^^jevel competition (e.g., Co^use^^e's electroScstore- 

usmg,fe example, the fcternet as a transport me^™ ^ ^^^^ versusAmerica OnlinX customer electronic 

transmit date representmg puich^e requests between a ^ characterizes ical-world commerce. The 

propnetary browser and server product pan. architectures are also too flat to support the complex intcr- 

For example, Netscape Co™«ations uses its j^y^i i^^^^dts (e.g., manufacturer-distributor-retailer 

NavigatormetsiteWoridWideWeb{WWW)browsei/servcr relationships) that characterize real-world commerce, 

pair. A buya uses a Navigator to sdect a seUer s Netsite 30 Finally, the architectures do not accommodate the marketing 

server (sort of an cleetromc storefront), which in turn ^^^^^ ^^^^ generation. Overall, the 

coupled to standard application servers (back-end architectures may be thought of as electronic cata- 

subsystems), e.g., a ^edit server or a member servw for , architectures rather than general electronic coimnerce 

collecting demographic infomation on customers. These ardiitectures. 

servers contain the business rules defined by the seller, e.g., 35 

what credit cards are accepted and what customer infonna- OBJECTS OF THE INVENTION 

tion is tracked during eadi salt^ Some of these severs are jj fl,erefore. an object of the invention to provide a 

comiected to external, third-party services, e.g., the credit ^ fadUtating commercial transactions over a com- : 

serv« to an external credit card processmg network or the ^^^^ of providing communications 

member server to an extmial demogn5>hics processing 40 between a supplier and at least one customer site associated 

module. TTic actual apphcations e.g., on-line pubhshmg or ^^^^ wctaiSing an input means and a 

catalog sales, are represented as extensions of the applica- disnlav 

tion servers. Equivalently, the mplication servers are said to 7, ^ * * • 

be instantiated in the implications. The net result of this / ^^^^ ^ P^^?^^ ^ 

approach is that the buSness rules (from the application 45 cleetromc commerce computer architecture which am 

^ers) are embedded into the appUcations alonl with the accommodate a wide variety of implementaUons. For 

aoolication loeic cr presentation exanq>le, the architecture should accommodate the use of 

-.1.- t- r J- J * commerce implementations currently being used for physi- 

This model has a number of disadv^tages. First, ^e oommcrcTwith Utfle modification, 

system is limited to a single communications platform, the ^ . ^ ^. * ... . ^. . , 

Internet ThisisbecausetheNavigator/Netsitesoftwareused 50 . mvenbon to provide a^al 

to implement the model is dependent on the Transmission "nplementations of some commerce subsystems where 

ConSl ProtocolAntemet Protocol (TCP/IP) used in the existing commerce subsystems used for physical commerce 

Intemet TTie model has no provisions to aUow communi- (^'S- marketmg subsystems) are not reacUly extendible to 

cations to platforms not using TCP/IP, for example, inter- electronic commerce or where those subsystems do not 

active TV. Second, in the Netsc^ model, business flex- 55 eurrently exist. 

ibility is low because of tiie intermingling of business rules It is still another object of the invention to provide an 

and application logic. It is more difScult to raodiiy a portion electronic commerce conq)uter architecture, comprising a 

of the resulting monolithic application than it would be to famUy of interconnected commerce subsystems, where 

modify a portion of a smaller module of a modular appli- changes can be made to one subsystem without affecting the 

cation. TTiis may have negative iixq)acts on reliability and 60 other subsystems. 

availability, because in certain cases it may be necessary to It is yet another object of the invention to {xrovide an 

shut down the system to make changes that must be syn- electronic commerce systcnit comprising a family of inter- 

chronized between two or more components. Third, such coimected commerce subsystems, where the subsystems can 

electronic catalogs support product display and secure pay- be distributed across many different platforms and networks, 

ment processing, but not the marketing activities needed to 65 Yet a further object of the invention is to provide an 

induce customers into reading the electronic catalogs. Thus, electronic conunerce system which closely repUcates com- 

there are no counterparts for physical commerce activities mercial transactions in everyday life. As such it is another 
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object of the invention to provide for an electronic assistant customer payment for the desired item. The payment handler 
to assist a customer during interactions with the system to is responsive to communications from the customer moni- 
fadlitate electronic commercial transactions. toring object. Also, the customer monitoring object is con- 
SUMMARY OF THE INVENTION figured to confirm to the customer that the order for the item 
^ ^5 has been successftdly processcd. 

Briefly, therefore, this mvenuonpr^^ Furthermore, the system includes a payment validation 

facilitating commercial transactions, between a plurahty of ruruicnuore, uic mwuucd a pa^rujcm vouuauvu 

^ J * 1 ♦ ^ i: fzt^^c system by means of which the customer momtonng object 

customers and at least one suppliar of items. The commcr- ^ , \, . ^ ^. i * j * *u * 7^ * 

dal transactions occur over a computer driven network information related to forms of payment 

capable of providing communications between the suppUer ^^f^^ ^ ttie customer and presents the custonKX widi a 

anLleastCcustomersiteassodatedwitheachcustoW^^ sekction of toe f^ of payment.lh^^ 

Each site includes an associated display such as a personal Lf^^t secunty code, related toa selected form of payment 

computer, set-top box, a touch sensiSve screen, a toid» tone Thereupon, the fir^ '^^^^ V^"^^ ^ "^7"^' 

telephone or any othW device capable of reproducing to ^ a second s^unty code available to the cust^ner 

audio or video Monnation to a human being. Each site ^, f^f^^^i^^^^^^" ^ "^"^^ ^ 

typicaUy also includes an input means such as a keyboard or validated. 

conmuter "mouse" through which the customer can input The system of the invention also allows for incentives to 

information into the system encourage the customer to con^lete a transactions. Such 

nic system of the invention faciUtates the presentation of incentives could include cost reductions such as price dis- 

at least one supplier on the display for selection by the ^ coimts. MorimiUon r^aidmg these cost redu^^ 

customer using tfie input means. SimUarly items from a within the system, often m assoaaUon with specific infor- 

suppUer can be displayed for the customer to observe. °^^o° ^^^^ totoe customer and also assoaated with a 

Associated with a suppUer of such items Is an item database ^uppUer s itemsjhe pricing means receives relevant p^ 

including information on presented items. Pricing means of t^e cost reduction information to calculate the cost of the 

receivcsinformationfromtheitemdatabasetodeterminethe „ assodated item lypicaUy, the customer momtormg object is 

costassodatedwithapresenteditemlnadditionacustomer ^ configured to receive cost reduction informaU^^ 

information database stores information relating to the cus- ^ate the reduction inf(Hmation to the pncing means, 

tomcri The system also comprises means for creating a The customer monitOTing object is also configured to 

customer monitoring object for each customer. confirm to the customer that the order for the item has been 

The customer monitoring object is created by referencing ^ successfully processed 
information, relating to that customer, whidi had been stored The system of the inyention further comprises supplier 
in the customerinformation database andwhcn the customer control means for rccdving input, from a supplier, for 
selects a supplier. The customer monitOTing object is con- changing the cost reduction information. One way of doing 
figured to operate by responding to customer enquiries, this is by having the supplier control means receive an input, 
communicated through the input means, regarding a pre- 35 from a supplier, at a first time defining changes to the cost 
sented item by accessing the item database to retrieve reduction information for a second time later than the first 
hifonnation relating to said item and to present said infor- time. This enables a supplier to define in advance both the 
mation to the customs by means of the display; receiving a timing and the magnitude of the discount that is ^plicd. 
customer's selection of a presented item through the input The customer monitoring means can be "short lived** and 
means; comiminicating with the pricing means to cause the ^ cease to opmXc on the termination of a transaction. Trans- 
cost of the item to be detennined; presenting the cost to the action termination is generally effected by a conomand from 
customs' by means of the display; recdving customer the customer. Alteratively, when the customer terminates 
coimnunicatLons, through the input means, indicating a interaction with the suppHer, the customer monitoring object 
desire to recdve the item; and passing a delivery initiation could temporarily cease to operate. In this case, information 
communication to initiate the delivery of the item to the ^5 regarding at least the interaction is stored for retrieval at a 
customer. subsequent time at which the customo^ interacts with the 

The customer monitoring object can also be configured to supplier. At that time the customer monitoring object recom- 

maintflin a list of selected items and to present the customer mcnccs operation without being recreated, 

with a total cost of all selected items for approval before the The system further comprising a means for accessing the 

customer monitoring object passes the delivery initiation 50 customer information database and for creating a particq)ant 

conmiunication. As part of this function, the customer program object The paitidpant program object indudes 

monitoring object could be configured to present the cus- customer specific information retrieved from the informa- 

tomcr with an opportunity to desdect an item whereupon the tion database. The partidpant program object is in commu- 

customer monitoring object causes the total cost of the nication with and electronically represents the customer to 

remaining selected items to be redetermined and presented 55 the customer monitoring object The partidpant program 

anew to the customer. object is created at the time an interaction between the 

The system further comprises an order fulfillment initia- customer and the system commences. It preferably indudes 

tion system, responsive to the delivery initiation communi- information related to forms of payment available to the 

cation from the customer monitoring object, for initiating customer. 

proceedings to cause the item desired by the customer 60 The system may also comprise an observation system for 

delivered to the customer. To enable this, it is preferable that receiving and maintaining customer interaction infcimation 

the order fulfillment system indude an interface with a rdating to at least one customer's communications over the 

shipping facility for facilitating the shipping of the desired computer driven network. Preferably, the supplier control 

item to the customer. T^ically the shipping facility will be means is in communication with the observation subsystem 

an existing facility known in the art 65 andrecdves customer interaction information for display to 

To arrange payment for any transactions, the system of the the supplier. The supplier control can indude an inf onnation 

invention further conqxrises a payment handler for initiating processor for processing recdved customer interaction 
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infonnation; and means for selectively displaying at least a 
part of &e i^ocessed customer interac^on infoimatiOD to the 
supplier. 

Additional features of the invention will become apparent 
upon examination of the description which follows particu- 
larly with reference to the acconipanying drawings. 

DESCRIPnON OF THE DRAWINGS 

In the accompanying drawings: 

FIG. 1 is a schematic representation of an electronic mall 
exeiiq)lifying fee electronic commerce architecture of this 
invention. 

FIG. 2 schematically depicts an embodiment of the inven- 
tion configured to support transaction processing. 

FIG. 3 depicts a compartment level view of the system of 
FIG. 2. 

FIG. 4 depicts a compartment level view of fee system, 
similar to feat in FIG. 3 but wife a plurality of Storefront 
Systems. 

FIG. 5 schematically represents an outline transaction 
using fee system of fee invention, 

FIG. 6 depicts fee completion of the online transaction of 
HG. 5. 

FIG: 7 depicts fee process by whidi a customer selects 
items for purchase in an online transaction of HG. 5. 

FIG. 8 dqjicts fee conq)letion of fee online transaction in 
fee commerce system illustrated in FIGS. 5 to 7. 

FIG. 8A depicts fee steps of FIG. S performed by fee Sales 
Representative Program Object 

FIG. 8B depicts fee steps of FIG. 8 perfcsmed by fee 
Payment Handler Interface and Participant Program Object 

FIG. 9 dqjicts one example of fee use of a User Interface 
to select fee preferred payment mefeod. 

FIG. 10 schematically illustrates fee creation of incentives 
in fee system of fee invention. 

FIG. 11 depicts a Pricing Rule Structure. 

FIG. 12 depicts fee operatioa of a Dashboard Client to 
maintain fee data needed to operate a storefront 

FIG. 12A depicts one view of fee Dashboard Client as it 
^>pears to a storefront operator. 

FIG. 12B depicts a second view of fee Dashboard Client 
as it appears to a store&ont operator. 

FIG. 13 is a flowchart that depicts fee operation of fee 
EVicing Engine ^plying Coupons according to fee inven- 
tion. 

FIG. 14 schematically illustrates fee registration process 
of fee Observations Subsystem 

FIG. 15 schematically illustrates fee event notification 
process of fee ObsOTations Subsystem. 

DESCRHnON OF EMBODIMENTS 
L Overview 

This invention relates to a conqHiter architecture for 
on-line commerce which defines an electronic infrastructure 
to enable a full range of commercial transactions analogous 
to feose occurring in physical commerce. 

It is evident feat a paitidpaot in electronic commerce 
might include a manufacturer of goods selling to a 
distributor, a distributee buying from a manufacturer and 
selling to a retailer, or a retailer buying from a distributor 
and selling to a consumer. The items sold need not be limited 
to goods, but could also include services such as videos 
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downloaded to a viewer's multimedia display, as well as 
delivexyless transactions such as selling stock shares held in 
a central repository. 
The Electronic Mall 

5 It is useful conceptually to think of electronic conomerce 
as exemplified by an electronic mall comprising a collection 
of suppliers of items such as goods or services, such as 
electronic stores, analogous to a physical mall conqirising a 
collection of physical stores. In this example, each commer- 

10 cial transaction constitutes a sale from an electronic store to 
a customer of fee electronic stcKc, where a customer can be 
any participant in fee electronic commerce architecture. 

It should be noted, however, that electronic malls and 
stores are of vasdy broader scope fean feeir physical coun- 

15 terparts because the electronic mall can contain electronic 
stores composed of independent functional subsystems 
located at various platforms and networks in an electronic 
hyperspaoe encompassing fee Internet, interactive TV, exist- 
ing legacy systems, and many ofeer electronic venues. 

20 Moreover, fee electronic store is not limited in geographical 
reach (e.g., a national store is possible), in goods sold (e.g., 
physical products, digital infonnation, and deliveryless 
transactional services are all possible), or to customer- 
merchant relationships (e.g., an entire distribution chain 

25 from manufacturer to consumer can be accommodated). 
FIG. 1 shows an electronic mall, generally indicated as 
10, that exemplifies fee electronic commerce architecture 
provided by this invention. A Customer 12 enters fee elec- 
tronic mall via a user interface 13, where fee customer is 

30 presented wife a choice of displayed Electronic Storefronts 
14. The user interface 13 may be a personal conqjuter, 
set-top box, a touch sensitive screen, a touch tone telephone 
or any ofeor device capable of reproducing to audio or video 
information to a human being. It typically includes an input 

35 means such as a keyboard or computer "mouse" through 
which fee coni^uter can input infonnation into fee system. 

The customer enters a particular electronic store by select- 
ing its Electronic Storefiront 14, e.g., by clicking on an icon 
wife a conventional selection or input device such as a 

40 mouse/curser device touctq>ad. As fee customer enters fee 
store. Internal Commerce Subsystems 16 are invoked by 
Electronic Storefront 14 to represent fee store's interactions 
wife fee customer. 
As fee customer decides what items to purchase, External 

45 Commerce Subsystems 18 may be invoked to conq)lete fee 
transaction. For example, VISA'S credit card network may 
be used for payment followed by FedEx's Powership shq>- 
ping management software for shipping. 

In the meantime, fee store's management can use a Store 

50 Management Dashboard 20 to interface and control fee 
Commerce Subsystems 16 and 18; for example, to establish 
in-store sales as incentives to fee customs. 

The Internal Commerce Subsystems 16, External Com- 
merce Subsystems 18, Electronic Storefront 14, and Store 

55 Management Dashboards 20 interact wife each ofeer 
through Internal Commerce Subsystems Interfaces 24 and 
External Commerce Sul>systems Luteifaces 22. 
n. Subsystem Overview 

Following from the above it may be apparent that each 

60 electronic store in .an electronic mall must be able to manage 
customer information, support targeted advertising, perform 
market research, execute on-line marketing programs like 
discount pricing, and ensure secure and reliable order and 
financial transaction processes, all within fee context of its 

65 own operating style. 

This invention provides such flexibility at fee individual 
store level while supporting simultaneous transactions 
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among a plurality of electronic stores, by defining a family tion provides only standardized interfaces to the commerce 

of elementary Commerce Subsystems 16 and 18 necessary subsystems, while in the latter, the invention can provide 

to support the various elements of electronic conunerce, and actual subsystem implementations as well as the interfaces, 

allowing each store to select a particular combination of This distinction provides great openness and flexibility by 

subsystems interconnected in a particular patto-n to suit its 5 allowing electronic conmierce participants to select Bxtenial 

particular operating style. Commerce Subsystems from a variety of currently existing 

It may be useful to think of these Coimnerce Subsystems business subsystems, while providing Internal Conmierce 
as "distributed objects" accessible to various of the stores Subsystems for those Commerce Subsystems where cur- 
and indeed to multiple stores, at die same time. Although not rently existing business subsystems either do not exist or are 
illustrated in FIG. 1, these Commerce Subsystems include: 10 unadaptable from physical to electronic conunerce. In either 
an Incentives Subsystem; an Observations Subsystem; an case, the architecture provides standardized interfaces 
Order Fulfillment Subsystem; a Participant Subsystem; a through which Commerce Subsystem implementations corn- 
Payment Handler; a Pricing Subsystem; a Product Database; municate with the architecture. Thus, the distinction 
a Promotions Subsystem; a Sales Representative Subsystem; between External and Internal is somewhat arbitrary, as it 
a Redemption Registry; a Security Subsystem; a Shipping 15 reflects the coimncicial availability of existing subsystem 
Subsystem; and a Tax Subsystem technologies rather than any fundamental difference 

The Customer Accounts Subsystem i s a store-spe cific between the two subsystem categaies. 

repository whid Blmld^mEfSS^ sgi^ffi^tsgeit'^^ Thus, eadi of the Internal and External Commerce Sub- 

crs* demographics and payment habits. Likewise, tht Incen- systems is a self-contained, independent module connected 

tives Subsystem is a marketing module which allows stores 20 into the architecture through a standardized interface. The 

to establish discount programs such as in-store sales, modules as a whole can be arranged in any combination for 

coupon-based discounts, frequent buyer programs, and any particular store. Note that the above categorization of 

quantity discount cards. Commerce Subsystems as Internal or External is exemplary. 

Similarly, the Participant Subsystem is a shared repository not mandatory. That is, a particular subsystem may have 
within the system architecture which stores general infor- 25 both Internal and External embodiments. For example, some 
mation on participants conducting electronic commerce with vendors may develop proprietary External Commerce Sub- 
each other. The participants might include manufacturers, systenas to replace the Internal Commerce Subsystems origi- 
distributors, retailers, and customers; and information might nally provided by this invention. In those cases, the system 
in dBteirai tKS«and«i aailinfiaadMdircsses, i ||g gf^ payment architecture would be able to accommodate either an Inter- 
mc^odsJ^S!'^""^"***^^*'*"**^^ 30 nal or External implementation of the Commerce 

For exan^)le, in the case of a housdiold con^jrising Subsystem, with each electronic commerce participant being 

multiple customers, some customer data wiU be household- able to select a combination of specific ira$)lementations that 

specific (e.g., a single shipping address) while other cus- best suits the particq)ant's needs, 

tomer data may be customer or store-specific (e.g., Mom*s External Cootnmerce Subsystems 

Macy*s aedit card number). This separation of household 35 Many existing Commoce Subsystems used for physical 

and customer data would also be useful for promotions commerce can be used for electronic commerce without 

based on household demograi^cs, and other ^plications, modification. These technologies are referred to as External 

where it is not necessary to send repeat advertisements to all Commerce Subsystems. Sudj subsystems operate identi- 

members of a household. cally whether the sale occurs in a physical ot electronic 

The Observations Subsystem provides a system for 40 store, so that their implementations are the same in botii 

recording events representing observable data that results physical and electronic commo-ce. They could include: 

from customer interactions. A i^ogram object called a **col- Customer Accounts Subsystem, Participant Subsystem; 

lector" communicates events to an event recipient. The event Order Fulfillment; Payment Handler, Product Database; 

recipient can either record the event for subsequent histori- Shipping; and Tax. 

cal analysis, or present it for real time analysis. 45 Examples of well-known existing implementations of 
The Electronic Storefront, whidi is analogous tea x^ysi- these subsystems are: VISA'S computerized aedit card 
cal store's physical layout, is the gr^hical user interface network (Payment Handler), various catalog sales' central 
presented to a customer browsing that store. warehouse operations (Order Fulfillment), FedEx's on-site, 
The Store Management Dashboard 20 allows store man- personal con^uter-based shipping calculator (Shipping), 
agement to change prices, offer incentives, collect customer- so and AVP's tax calculator (Taxing), 
based and stOTe-based sales data, and perform targeted Many physical steles will have different External Corn- 
advertising, i.e., interact with the various Internal and Exter- merce Subsystans that they will want to continue using in 
nal Commerce Subsystems discussed earlier. It is anticipated the context of an electronic store. For exanq)le, other Pay- 
that stores will want to use their own proprietary Electronic ment Handler systems might include CheckFrce's automatic 
Storefronts, so the architecture provides an interface to be 55 check handling system for non credit-card aocqptors or 
used by an existing Electronic StOTefront rather than pro- in-house "legacy systems" for large department store chains, 
viding the Electronic Storefront itself. For example, existing Therefore, the system architecture nmst accormnodate a 
commercial services having proprietary electronic store- wide variety of existing subsystems. Rather than developing 
fronts (e.g., America Online' s or Conapuserve's home shop- new subsystems to displace individual stores' established 
ping forums) will probably want to continue to use those eo preferences, the system architecture provides a set of appli- 
storefronts even if they become networked into a broader cation program interfaces (APIs) through which owners or 
electronic comment architecture provided by this inven- vendors of External Commerce Subsystems can easily 
tion. '*wr£q)" their products for connection to the general system 
Architectural Openness and Flexibility architecture. . 

As discussed briefly above, the Commerce Subsystems 65 Internal Conunerce Subsystems 

may be categorized as either external or internal. The The remainda- of the Conmierce Subsystems are called 
difference between the two is that in the former, the inven- Internal Commerce Subsystems — those where existing sub- 
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systems for physical commerce can not be directly used in graphic data, and methods available to the participant for 

dectronic commerce, so that separate electronic counter- payment Access by a store to the information about a 

parts must be developed for use by electronic stores. participant is controlled by a flexible mechanism in the 

Such Internal Commerce Subsystems might include: Participant SubsystenL This mechanism supports enforce- 

Incentives; Observations Subsystem; Participant Sub- 5 ment of a variety of privacy policies. These policies may be 

system; Pricing; Promotions; Sales Representative; and specified by the operator of the Commerce System, by the 

Security. individual participant, or by a combination of the two. 

Some of these subsystems, though not currently in exist- Different privacy policies may be specified fcff each element 

ence fOT use in electronic commerce, nevertheless use well- of the participant data for each individual customer. The 

established, commercially available technologies. These lo policy data is stored with a Participant Program Object 112 

could include Oracle or Sybase databases for the database as part of the privacy controls, in a Participant Subsystem 

components of the Observations and Participant which will be described in greater detail with reference to 

Subsystems, and RSA Public Key encryption technology for FIG. 5. 

the Security Subsystent These Internal Commerce Sub- For eadi payment mettiod, the Partic^>ant Program Object 

systems are developed by simply wrapping the aforemen- is 112 contains a short token used to describe the payment 

tioned technologies with the appropriate hooks to interface method and a password that will be used to validate attenq}ts 

with the standardized APIs. Ibe process is similar to that to use the payment method. 

third party developers would use to create interface- Typically, the Participant Program Object 112 is created 

compatible External Commerce Subsystems. for a participant 12 at the time tiiat the participant is 

The four remaining Internal Commerce Subsystems, 20 registered with the electronic service from which he or she 

which are not generated by modifying existiag technologies, will interact with the commerce systenx For exanq)le, if the 

are the Incentives Subsystem, the Pricing Subsystem, the electronic service is an online service such as Con^userve 

I^omotions Subsystem, and flie Sales Representative Sub- or America Online, a Participant Program Object 112 is 

system. The details of these will be apparent from a reading created at the time the customer enrolls with the online 

of the specification as a whole. 25 service. Likewise, if the electronic service is a cable televi- 

TTT Inyjlementation sion provider, a Participant Rrogram Object 112 is created at 

To implement the above, and as will be apparent from the the time that the participant 12 begins subscribing to the 

descrq>tion of FIG. 2, the system comprises a set of program cable television provider. In this way, sensitive information 

objects. _ such as credit card account numbers and passwords may be 

.^gp(r^£Ux:kipbject^isfanfintegFatedH^ 30 provided using a secure means at account initiation, 

^ctions that describe an cntityOT bu^^^^jn^^and The Participant Program Object 112 communicates with a 

thtitott ^^f^ Siitfaatica ntbeipCTf^ ^ Customer Monitoring Object or Sales Rqnesentative Pro- 
business function, tlS^^ds^KSjSS^^Sf^^^^^^^^ gram Object 114. Sales Representative Program Object 114 
dS&S^m m ^ ^th ^ M^ ^io^ ^^^^^^'^^^^^^^^ ^^ is a program object that is created when the customer selects 

tj^ AttffiO ^lgFhc program obj^^iiiay'^b&^Kr^an^ife, 35 a store. The Sales Representative Program Object 114 has 

o bi»gtr>^n^com^ access to information, kept by the store, about die customer 

(OMG's) C6n®n''^0Sjert'^Req^ Architecture and also controls the flow of a transaction processing session 

(CORBA). and forms part of an Internal Commerce Subsystem 16 

CORBA provides mechanisms by which objects naay shown in FIG. 1. As will be described in detail. Sales 

transparently make requests and receive responses. CORBA 40 Representative Program Object 114 is used to obtain inf<^- 

also provides for an Object Request Broker (ORB), which mation regarding items that are the subject of the 

provides interoperability between applications on different transaction, and initiate clearance for payment and order 

conq>uters in heterogeneous distributed environments and fulfillment 

seamlessly interconnects multiple object systems. The The Sales Representative Program Object 114 is analo- 

advantage of compliance with an architecture such as 45 gous to a sales representative in a store. Just as a sales 

CORBA is that the program objects may be distributed representative has the responsibility of monitoring the cus- 

among various computers according to the business needs tomcrs activity by being aware of prices of products and 

and responsibilities of the entities involved in the system. discounts available to the customer, and by initiating 

FIG. 2 illustrates a number of the program objects nec- completion of the transaction, the Sales Representative 

essaiy to implement an embodiment of the invention. As 50 Program Object 114 carries out these tasks in the onHne 

such, the figure shows a plurality of program objects inter- commerce systenL 

acting to support the execution of a commercial transaction. Interaction between the Sales R^esentative Program 

To begin with, a participant or customer 12 into^cts with Object 114 and the customer 12, to communicate informa- 

the system 10 by way of a usa interface 13. User Interface tion about, for example, items desired to be purchased, is 

13 may be in the form of a video terminal, a cable television 55 through the User Interface 13. 

set-top device, a touch-sensitive kiosk screen, a touch-tone The Sales Rqxresentative Program Object 114 communi- 

telephone, or any other device or combination of devices cates with a R'oduct Database 116 through Pddng Engine 

capable of reproducing or otherwise displaying human Intel- 120. Product Database 116 is part of tbc External Commerce 

ligible audio and/or visual infannation to a customer 12 and Subsystems 18 and is a con^uter file or set of computer files, 

capable of converting human input to a discrete signal 60 including, if necessary, supporting software components for 

capable of being recognized by a con^>uter. the retrieval of data. Product Database 116 includes infor- 

Notwithstanding this interaction, however, it is a Partici- mation regarding items that are offered as the subject of 

pant Program Object 112 that represents the customer 12 in transactions. This information includes the name of the item, 
the commerce system. The Participant Program Object 112 item identification numbers, standard price for the item, 
contains information that identifies the participant 12, and 65 manufacturer, etc. The Product Database 116 may be iix^le- 

additionai information about the participant, for example, mented using any of a number of commercially available 
the participant's name, address, privacy controls, demo- database systems, such as Oracle or Sybase. The Product 
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Database 116 accepts fuDCtion calls from the Sale Rcpre- In the example depicted in this FIG. 2, Participant Pro- 

sentative Program Object 114 to provide infonnation about gram Object 112 and Usa* Interface 13 are configured in 

a particular item. w**^' ^ ^ caHcd a Customer Contact System 140. Cus- 

AIso cffOYided is Distributor Program Object U8, which tomcr Contact System 140 may be, fa example, an online 

is part of the Internal Commerce Subsystems 16, and is a 5 service suc^ as Compuserve or America Onhne an apph- 

priram object that provides information regarding Cou- f^tion interface at a cable television site ^^cessedr^^^^^ 

^^119 to the Electronic Storefront 14. Coupons L data "r^^, t ^^^^^ ^"^Jl ^ Worid^Wide Web 

" " , ^ . ^ . „f (WWW) site on the Internet accessed by a customer usmg a 

smictures ttiat describe mcendve programs m ±t form ^ ^ ^^^^ application across a TCP/IP connection 
discounts that made available to the customer to encourage similarly, the Sdcs Representative Program Object 114, 
puidiase of items, and are further descnbcd below. lo Database 116, Pricing Engine 120, Tax Engine 122, 

A Pricing Engine 120 is responsive to function calls from shqiping Cost Engine 123, Payment Handler Interface 124, 
Sales Representative Program Object 114 is also provided. External Payment Handler 126, Order Ftdfillment Sub- 
Pricing Engine 120 is a program object that provides infor- system 128, and Order FUfillment Legacy System 130 are 
mation about the price of a set of items selected for purchase, configured in an In-Store Processing System 142. In-Store 
The Pricing Engine 120 accesses the ftoduct Database 116 15 processing System 142 may be, for example, a con^)Uter 
to determine attributes of selected items, and i^lies incen- system used to administer one or more of the electronic 
tives obtained from Distributor Program Object 118 to Storefronts 14 shown in FIG. 1. 

determine a pice that will be charged to the customer. FIG. 3 depicts only the compartment level view of tiie 

The Tax Engine 122, part of External Commerce Sub- system depicted in FIG. 2. In-Store Processing System 142 
systems 18, is a program object tfiat determines what tax, if 20 is depicted in communication with Customer Contact Sys- 
any, should be applied to a particular transaction, based upon tern 140. 

the items that are the subject of the transaction, the geo- As an expansion of tiiis view, FIG. 4 depicts a con^art- 
graphical locations of the participant and the electronic ment level view of the system, with a plurality of In-Store 
commerce system, etc. The Tax Engine 122 is responsive to Processing Systems 142. In such a configuration, the com^ 
function calls from Sales R^resentative Program Object 25 merce system operates to facilitate commerce with multiple 
114 and may be in^lemented, for example, using a com- commercial entities, analogous to the shopping mall sup- 
merdally available tax calculation system, such as the AVP porting multiple stores as described above. 
Tax Engine. IV. Transaction Processing 

The Shipping Cost Engine 123, part of External Com- Overview of an Electronic Store Transaction 
merce Subsystems 18, is a program object that determines 30 To more fully understand the operation of the invention, 
the cost, if any, of shipping purchased items to the location it is useful to concentrate on a transaction in a single 
designated by the customer, based upon the properties (such electronic store. FIG. 5 shows an overview of a sin^lified 
as weight, size, and special shipping requirements) of the logic flow for a typical transaction, 
items that arc the subject of the transaction, the geographical A Customer/Participant 12 enters an electronic storefront 
locations of the participant and the electronic commerce 35 14 and is presented with the store's Product Database 116 in 
system, etc. The Shipping Cost Engine 123 is responsive to connection with in-store sales, presented by the Sales Rcp- 
fiinction calls from Sales Representative Program Object resentative 114 tog^er with an Incentives Subsystem 160 
114 and may be implemented, for example, using a com- and nanowcast advertising targeted at the Customer throu^ 
mcrdally available shipping cost calculation system. a Promotions Subsystem 162 based on tiie Customer's 

Payment Handler Interface 124 is provided to initiate 40 demographics or purchasing habits as defined by a Partici- 
payment for a transaction. This is a program object that is pant Subsystem 164 and Customer Accounts Subsystem 
responsive to Sales Representative Program Object 114. 117. 

Topically, the Payment Handler Interface 124 will serve as In response, the Customer passes product or service 
a front-end to convert an object-oriented function call, such selections to the Sales Rq)resenUtive 114. The Sales Rcp- 
as a CORBA call, to a call to an External Payment Handler 45 resentative 114 obtains pricing information from the Incen- 
126, part of External Subsystems 18. The External Payment tives Subsystem 160 to get pricing rules, and then passing 
Handler 126 may be implemented using a commercially the selection list and the pricing rules to the Pricing Engine 
available payment handling system, such as Visa Corpcx-a- 120, which calculates and returns discounted prices by 
tion's YCSAnet (not shown). matching the selection list against the pricing rules using 

To initiate delivery of the selected items to the customer so product infcrmation from the ftoduct Database 116. 
Order Fulfillment Subsystem 128, a program object tiiat is The Sales Representative 114 then calls subsystenis such 
responsive to Sales Rq)resentative Program Object 114, is as Tax Engine 122 to calculate Tax and Shipping. Thereafter, 
provided, T^picaUy, the Order Fulfillment Subsystem 128 the Sales Representative 114 returns a total price to the 
will serve as a front-end to convert an object-oriented Customer 12, who returns a final order to the Sales Repre- 
function call such as a CORBA call to a caU to an external 55 sentative. 

subsystem that performs order fulfillment An exanq)le of Thereafter, die Sales Representative 114 arranges for 
such an external subsystem is Order FulfUlment Legacy Payment This includes querying the Customer for a pay- 
Subsystem 130. The Order FulfUlment Legacy Subsystem ment method (e.g., VESA card) and a means of authenticat- 
130 may, for exanq>lc, be a store's existing subsystems for ing the identity of the Customer (e.g., a password); querying 
delivering a product cf a service to the consumer. 60 tiie Participant Subsystem 164 for payment iirformation 

This figure also depicts one possible configuration of corresponding to the payment metiiod (e.g., looking up the 
components distributed among multiple logical conqjart- customer's VISA card number, which is secure from die 
ments of the commerce subsystem A logical compartment store); calling a Payment Handler 126 to validate the pass- 
may be a distinct computer system, ot it may be a set of word and to authorize the credit transaction with an external 
resources in a computer system or set of ooiiq}uter systems 65 payment network (not shown), e.g., VBAnet 
to which the enterprise responsible f the compartment has Next, the Sales Representative 114 transmits the cffder to 



access. 



the Order Fulfillment Subsystem 128. Order Fulfillment 
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Subsystem provides Sales Representative 114 with a recdpt 
to be placed in the Participant Brogram Object 112 as an 
indication that the order has been processed; calls Ordo* 
Rilfillment Legacy System 130 to airai^e for delivery of 
goods to the customer; and calls Payment Handler Interface ^ 
126 to settle the payment Order Fulfillment Legacy System 
130 also feeds back data to update the Farticq)ant Subsystem 
and the Store Sales database, part of Observation Subsystem 
168. 

D^ails of the Transaction 

The above reflects an overview of a typical transaction. To 
more fully understand and describe this transaction it is 
useful to divide it into its &ree phases: 

(b) selection of items to be purchased; and 

Eac^&^Wie^ases ?s delc^il^'^in^reater detail below; 
(a) Initiation of Session 

FIG. 6 depicts the initiation of a shopping session using 
the system of the invention. 

When the Customer 12 "enters" a Storefront 14, Partici- 
pant Program Object 112 is retrieved from the Participant 
Subsystem and activated. Store&ont 14 determines what ^ 
Distributor Objects 118 exist to distribute coupons that can 
be used by this storefront This may be accoinplished, for 
exan^le, through the use of a nameserver such as that 
specified by the COKBA Object Request Broker. Storefront 
14 calls Sales Representative Factory 115, passing to it the ^ 
Participant Program Object 112 and the list of Distributor 
Objects 118. 

Sales Representative Factory 115 is a spedal^mpose 
program object whose purpose is to create, or ^^instantiate " 
a Sales Rqiresentative Program Object 114. Sales Re|ffe- 
sentative Factory 115 instantiates a Sales Representative 
Program Object 114 in response to a request fix>m the 
Storefiront 14. Once created. Sales Representative Program 
Object 114 initializes itself. 

Sales Representative Program Object 114 obtains from 
Participant Program Object 112 any Coupons 119 that have 
been retained by Participant Program Object 112 from prior 
shopping sessions. Sales Representative Program Object 114 
also calls Distributor Program Objects 118 to obtain any 
additional Coiq>ons 119 that represent current sales in Store- 
front 14. 

After the Sales Representative Object 114 is aeated, it 
figuratively accompanies the customer through the store, 
provides pricing information, authorizes the purchase 50 
method (e.g., VISA), applies any applicable discounts (e.g., 
in-store price discounts or coupon-based jnlce discounts), 
and conopl^es the sale (e.g., ships the items and arranges fos 
payment). In one eoabodiment of the invention, the Sales 
Rqiresentative Object 114 is dedicated to the Customer 12 55 
until the Customer 12 completes that session but does not 
outlive a shopping session. In another embodiment of the 
invention, the Sales Representative Object 114 may span 
several sessions. The life of Sales Representative Object 114 
is terminated upon payment (or billing frequency), which is 50 
specified by Store Management. For exar^e, if billing is 
per session, the Sales Representative Object 114 only lasts 
for that session; but if billing is monthly, the Sales Repre- 
sentative Object 114 lasts for the entire month. 

The call to the Sales Rep Factory 115 to create a Sales 
Rqyresentative Object 114 may be coded using the CORBA 
Interface Defiiution Language (IDL) as follows: 



35 



40 



45 



intcrfece BV_SalcsRcp Fac { 

BV_^SaIesRep create_STep ( 

in BVPartictpant pazt, 

in BV_JncemiveiDistribijtoiLi5t dl, 

); 
}; 



65 



Here, a function create_srep of type BV_JSalesRep 
receives two inputs: part, of type BV_Parddpant (and 
identifying Participant Program Object 112); and dl, of type 
BV_IjDcentiveDistributoa:List describing a list of Distributor 
Program Objects 118. 

The first input, part is infoarmation on the customer's 
household transmitted from Participant Subsystem 164 to 
Sales Representative Object 114. The second input, dl, is a 
list of all currentiy available Incentive Distributors associ- 
ated with the store. 

Following initialization of Sales Representative Program 
Object 114, tiie Sales Representative Factory 115 passes a 
pointer to the Participant Program Object 112 to the Sales 
Representative Object 114. The pointer is a data area that 
indicates where its corresponding program object can be 
found. Thus communications between the Participant Object 
112 and the Sales Rqiresentative Program Object 114 can be 
established. 

In a simple nondistributed in9>lementation, the pointer 
may wxply be an address of the location in the computer's 
storage at which the pirogram object to which the pointer 
corresponds may t>e found. 

In more complex implementations, such as an implemen- 
tation capable of being distributed across multiple computer 
platforms, the pointer may be an object handle in the form 
of a token that can serve as input to an object request broker 
such as a CORBA-compliant ORB. Based upon the contents 
of a particular object handle, the ORB can then direct a 
request to use the services of a particular program object to 
that program object 
(b) Transaction E^ocessing 

Once the Sales Representative Object 114 is instantiated 
the customer may select item for purchase. FIG. 7 depicts 
the process by which a customer does so. User Interface 13 
presents the customer 12 with descriptions of items for 
potential purchase using any means capable of being 
employed by the User Interface 13. For example, a full- 
screen interactive system such as an online service or a 
WWW session may employ icons associated with various 
products and services, whereas an interactive cable televi- 
sion service may employ a product list that can be scrolled 
and firom which items may be selected using buttons on a 
remote control device. 

When the customer 12 selects items for purchase, User 
Interface 13 calls Sales Representative Program Object 114 
to inform that program object of the selected item. Sales 
Representative Program Object 114 maintains a Purchase 
List 170. In response to requests from User Interface 13 to 
select an item. Sales Representative Program Object 114 
validates the selected item against Product Database 116 and 
adds the selected item to tiie Purchase List 170. 

This is done using a call diat intecrogates the Product 
Database 116 for Product Data consisting of an item descrq>- 
tion and its list price at the time of selection. 

The selection of an item for purchase is not a commitment 
to purchase. It is analogous to a shopper placing an item in 
a shopping cart in preparation for a purchase. Just as a 
shopper may elect not to purchase a selected item. User 
Intraface 13 may also communicate to Sales Representative 
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Ftogram Object 114 that the customer docs not wish to of the mother of the household, the token might contain the 

purchase an item that has previously been selected. In string *'Mom*s Msa." 

response to such a call, Sales Representative Program (ii) Selection of Payment Method 

Object 114 removes the corresponding entry from Purchase in response to ou^ut from the function call given directly 

list 170. 5 above, and as shown in Step 181, Sales Representative 

Sales Representative Program Object 114 validates all program Object 114 caUs User Interface 13 to obtain the 

^plicable coupons against the store's Redenoption Database customer's selected niethod of payment As shown in detail 

172 (which is part of Incentive Subsystem 160) and obtains pjQ ^ ^ Representative Program Object 

the pricing rules for the incentive programs tiiat those 114 calls User Interface 13, passing to it the list of payment 

coupons rq>rcsent The Redemption Database 172 acrom- ^^^^j^^ ^^^^ cOTespond to the payment methods for 

pushes this by referencing the incentive programs recorded ^j^^ customer is authorized. User Interface 13 presents 

in the Redemption Database 172 and referenong the^cmg customer, for selection of a preferred payment 

rules from the corresponding Incentive ft-ogram Obje^. n^ethodandtheprovisionof a password necessary to authen- 

Optionally, during the cour^of selectog items for ^ieate his or her use of the payment method Tlie information 

purchase Sales Representative Pcopm^ presented to the customer 12 is described below in greater 

fticmg Engine 120 to determine the total cost of Ae tons reference to FIG. 9. User Intaface 13 computes 

currentiy selected and placed on Purchase Last 170. S^des ^ ,paa gBCBU-n h -^ --^~it f ..^^.u^^ ^ 

Representative Program pbject 114 pa^es the ^hase hst chaUSg^^^vides it to Sales Repres^tive Program 

and any appUcabk pricing rides to Paang Engine 120. ^ R^^B§g^|e,Si2iif?^^S!^^ 

Pricmg Engme 120 obtains additional item attnbutes from ^ tok siiiteeto pDDi ^ ^ts^wff^B te^ 

Product Database 116 and calculates the proposed total cost (iin ^ut^ Sdadon 

of the selerted items with discounts from appHcable incen- ^^^^^^^ ou tput from the fanction caU above, 

lives via the pricmg rules. . ^ ^ ^ ^ , ^ the payment method sel<5gtaWd*ttie?p'a!sWOTd^tCTed»b5» 

This total cost infonnauon is returned to Sales Rei^esen- ^^^jsS^sm'^SmSi^!^. In step 182, Sales Rqp- 

tatiye Program Object U4 Sales Re^esenta^veftogram /g^^^T;;^, object 114 receives the method of 

Object 114 provides this mformaUon to User Interfac^l3, ^ ^^^^^ ^ ^ {ajMliairthoEfeation token from 

whidi disidays It to the customer to approval or f« further jnu^^ico 13. In step 183, Sales Representative Program 

item selection and/or deselection. Has pnce calculaUon inay ^ ^ Payment Handler Interface 124 to vaUdate 

be performed, f<K exan^)lc, after every selection/deselection ^j^^^^ payment, passing to tiie Payment 

<^tion initiated by the customer, or m response to the ^^^^r Interface 124 the data received from the customer 
customer's specific request to gcnaratc a current total. 

Thereafter, the transaction can be completed. , ^ performed by 

(c) Transaction Completion , Payment Handler Interface 124 and Participant Program 

FIGS. 8, 8A and 8B depict tiie completion of an online ^ ^ ^ handler Interface 124 
transaction in die commerce system. Transaction completion ^ ^ ^^^^ Response to Oiallcnge token that was suppHed 
is performed by Sales Representative Program Object 114 m iVpically, tiiis will be passed by tiie Sales 
conjunction with Payment Handler Interface 124, as shown Representative Program Object 114 in the call to Payment 
in FIG. 8. HG. 8A depicts the steps P^on^ef by the Sales ^^^^^ ^^^^ ^ ^ p^y^^^^ j^^^. 
Representative Program Object 114 and ITO, 8B depicts the ^ Participant Program Object 112, passing to it 
steps performed by Payment Hanger Inte^^ ^ Response to Challenge token. Participant Program 
junction with Participant Program Object 112, HGS 8A and ^ calculates, in Step 183C, a reference pay- 
SB and should be referenced in conjunction with FIG. 8. ^^^^ authorization token. The reference payment authori- 
(i^ Obtaining Payment /^^ zation token is an encrypted tcdccn based upon the password 

In Step 180, Sales Representative Program Object^^^^^ Participant Program Object 112. In step 

caUs Partiapant Program Object U2 to obtam a hst of ^ Participant Program Object 112 compares the 

methods of payment that are available to toe customer. In Response to Challenge token received from User Interface 

response to the call, Partiapant Pro^ Object 112 passes ^3 reference payment authorization token, to vaH- 

to Sales Representative Program Object 114 a hst of all ^^^^ customer to use the selected 

payment me&ods tiiat the customer is autiicmzcd to use. payment metiiod. If ttie two tokens are equal, Participant 

The call may be in^lemented witii the foUowmg code: ^ program Object 112 provides to the Payment Handler Inter- 

face 124 the information needed to effect an authorization to 

voidpre5aie_to_buy( charge tiie selected payment method; generally tius will 

out BV_j>aynicntMomton:Payincnajst aiiaOi^ indude an account number, expiration date, cardholder 

out BV„Sa:urity::UseiChaUaige challenge) name, and the like, 

raises (BV_lnvaiidState); 35 In Step 183F, Payment Handler Intcrfaced^feycrifies tiiat^ 

the Participant Program Object has successfully verified the 

Parameters alias_list and challenge are outputs from the Response to Challenge. If so, in Step 183H, the Payment 

function. Handler Interface 124 calls External Payment Handle 126 

For cadi payment method, the Participant Program Object to obtain an authorization to charge. External Payment 

112 provides the Sales Representative Program Object 114 60 Handler 126 is typcaUy a con^utcr system operated by die 

with a short token used to describe the payment method and institution supp<Mting the payment method. For example, if 

a challenge that will be used to validate attenQ)ts to use the the customer selects a Visa credit card as a payment metiiod, 

payment mettiod. The token is a text string that identifies the then Payment Handler Interface 124 will call ttie VKAnet 

payment method using words that are familiar to the system for authorization to charge the selected Visa account 

customer, but does not contain any confidential information. 65 External Payment Handler 126 notifies Paynaent Handler 

For example, if a customer is authorized for a payment Interface 124 that the charge to the selected payment method 

method using the Visa credit card account held in the name will be accepted. 
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If the tokens aic aot equal, Payment Handler Interface 124 
in step 183G sets an indicator that the selected payment 
method was not properly authorized. Following either step 
1S3G 9r 183H, Payment Handler Interface 124 in step 1831 
returns control to Sales Representative Program Object 114. 5 
Typically, in this step Payment Handler Interface 124 may 
indicate success by supplying to Sales R^iresentative Pro- 
gram Object 114 an Authorization Object that describes the 
authorization to charge. 

In step 184, Sales Representative Program Object 184 lo 
checks whether Payment Handler indicated that the selected . 
payment method was not properly authorized. If it was not 
authorized, Sales Representative Program Object 114 
returns to step 181 to again prompt ttie customer to reenter 
the method-of-payment data, or optionally aborts the trans- 15 
action. 

One benefit of this method is that it avoids the transmis- 
sion of sensitive information such as credit card account 
numbers to Sales Representative lYogram Object 114. No 
account numbers are transmitted between User Interface 113 20 
and Sales Representative Program Object 114. 

(iv) Order Fulfillment 

Once authorization to charge been effected, and as shown 
by Step 185, Sales Representative Program Object 114 calls 
the Order Flilfillment Subsystem 128, providing it with the 25 
list of items ordered by the customer. Order Fulfillment 
Subsystem 128 typically calls an existing Order Fulfillment 
Legacy System 130 to generate shipping manifests and 
perform other activities needed to ship the selected products 
to the customer. 30 

(v) Generating Receipt 

Following step 185, Sales Representative I^ogram Object 
114 creates a receipt 192 and passes it to Participant Program 
Object 112 for storage to be used if later verification of the 
order is required. 

Typically, the step of creating the Receipt 192 may be 
accomplished by the steps shown in FIG. 8A. In step 186, 
Sales Representative Program Object 114 replicates Pur- 
chase List 170. Id Step 187, Sales Representative Program 
Object 114 then modifies the replicated Purchase list 170, ^ 
to indicate that the resulting data structure is a receipt, e.g., 
by setting a flag. In Step 188, Sales Representative Program 
Object 114 calls Participant lYogram Object 112, passing it 
the newly created receipt 192 for storage. 

(vi) Settlement 

When the selected products are indicated as shipped. 
Order Fulfillment Subsystem 128 calls Payment Handler 
Interface 124 to request the payment that previously autho- 
rized in step 183D. Payment Handler Interface 124 again 
calls Extemal Payment Handler 126 to convert the authori- ^° 
zation to charge to a payment order. 

(vii) LnplemcntatioD of Sections (iii) to (vi) 

The components of the transaction described above under 
Sections (iii) to (vi) are completed by the following calls 
which are described in detail below. 

Once the customer 12 has selected a choice of payment 
type, the Sales Representative Object 114 then calls a buying 
fiinction of the form: 



BV__Rcocipt buy ( 

in BV_JPaymeiitMomtor:a*ayineii^^ pflyinciit_type, 
in BV_PayiDentMonitar::UserNamo usei; 
in BV_Security::UscrReq)anse tesponse, 

in BY _£CX)lean CT temal p oym^'n^ jm<'fhrw4, 

in BY PaymcntMetbod epm 

) 
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-continued 

raises ( 

BV_CrcditAuth, 

BV_ShippiQgCa!c, 

BV,J>ricingCalc, 

BV_^edeinptio3if 

BV_FulfiIln>eiil, 

BV^Abort, 

BV_InvalidStatB 



This call peafcams a numb^ of steps including: 

(i) creating an invoice listing die items to be bought and 
the shipping destination, 

(ii) calling the Pricing Engine 120 to calculate a subtotal, 

(iii) calling the Order Ftilfillment Subsystem 130, 

(iv) calling the Tax Engine 122, 

(v) computing the total price for the order, 

(vi) authorizing payment for die (^der, 

(vii) fulfilling the order, 

(viii) redeeming coupons, 

(ix) returning unused coupons to the customer, and 

(x) creating a receipt for the customer. 
These stqps are discussed in tum, below. 

The first step is a call to the Pricing Engine 120 to 
compute a subtotal for the items in the customer's order. The 
Sales Rq)resentative Object 114 passes the customer's order 
and aU the currently existing Pricing Rules to the Pricing 
Engine 120, whidi returns a Total list Price, a Total Dis- 
count and an itemized price list 

The actual interface to the Pricing Engine 120 takes the 
form: 



B V—ATTienrtmenfT ,ist eval( 

in BV_JtanList tax;get_Jtaiis, 
in BV_JtanList baskcLJtems, 
in BV__InceiitiveLisLJiicciitives; 
out B V_Moncy totaLJist_pricc 
out BV.3Ione7 totaL.discount 

); 



The first two iI^)Uts, target_items and basket_Jtenis, 
together con:qirise die Customer's order. Target items are 
those items that are discountable. Basket_items are those 
items that are nondiscountable, but which may be required 
to supp<Ht discounting (e.g., they may contribute to meeting 
a quantity requirement). 

The third input, incentives, is a list of all currently existing 
store incentives. Each Incentive takes the form: 



struct BV_fticentive ( 

long application_cx»nt; 
boolean valiJ_with_otbcrs; 
BV_J*ricingRule rule; 

): 



where application^count is the number of times the dis- 
count may be applied; 

valid_with_others is TRUE if the coupon can be applied to 
items already subject to a pricing change and FALSE 
otherwise; and 

rule is the pricing rule defined by the Store Management via 
the Store Management Dashboard 20 (as discussed t>elow). 

The comparison of items to predicates (described in detail 
below with reference to FIG. U) uses a pricing algorithm as 
follows: 
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Set the total_lisL_price to SOjOO 
Set tl£ total_discoum to $0X)0 
For each item in tsr^t—itexns; 

Add the item's list price to the totaLJist_price 

If ifae item is do longer discountable, continue to next item 

Por each incentive: 

If the rule maiches and yields an adjustment, tbea Store the <item, incentive, rule, ac$u$tm£iil> 

quartet in an amy of results 

Mark item no bnger discountabk if the incentive is not valid with other offers 
If the ^justment is an amount* modify the totaL_<Uscount accordiiigly 

Eulif 

Eod this incentive; process next incentive in sequence 
Return tlK array of results to the Sales Rep. 



After computLDg the totaLJist^price and totaL-discount, 
the Sales Representative Object 114 invokes a subtotal 
functioD to calculate the subtotal=stotal_Jist__price-total_ 
discount The Sales Representative Object 114 then invokes 
a shipping_cost function to pass the order to an external 
Shipping Subsystem that calculates shipping costs. This is 
typically one of several existing legacy systems which 
interface to the electronic store through the electronic mall*s 
Shipping APL Similarly, the Sales Representative Object 
114 calls an external Tax Subsystem to calculate the taxes. 
Sales Representative Object 114 then adds the subtotal, 25 
shipping, and tax to give a total price. 

The next step is to authorize payment, as described above 
in detail. After the sale is authorized, any coupons 119 that 
were actually used can be redeemed (as will be described 
below). Any unused coupons 119 are released back to the 30 
Sales Representative Object 114 to be returned to the 
Partic^ant Rrogram Object 112 within Participant Sub- 
system 164. Such coupons will be available for use by the 
customer in subsequent shopping sessions, 
(viii) User Interface for Payment Selection 35 

FIG. 9 depicts one example of a User Interface 13 to select 
the preferred payment method as required by the system to 
the conqdete the transaction along the lines described above. 

In the example, User Interface 13 displays a screen image 
113. The screen image includes a display of payment options 40 
212. The customer 12 (not shown) is presented with three 
payment options: 1) "Mom's Visa"; 2) "Jim's AMEff^ 3) 
"Debit Jim's Checking Account." User Interface 13 also 
provides a means for the customer to indicate his or her 
selection of payment methods. This means is depicted as 45 
selection input area 214. The customer may, for example, 
type the number corresponding to the selected method of 
payment in this position. 

In addition, User Interface 13 provides a means for the 
customer to supply a password to authenticate his or her 50 
identity and authority to use the selected payment method. 
In the example, this means is depicted as password entry 
area 216. The customer may enter a password at that location 
on the screen. User Interface 13 then computes a payment 
authorizatioQ token using the password, and transmits the 55 
method of payment selection and the payment authcHization 
token to Sales Representative Program Object 114. 
v. Storefront Setup Overview 

Each electronic sto-e (represented by storefront 14) has a 
Store Management associated with it The Store Manage- 60 
ment interacts with the electronic store through a Store 
Management Dashboard 20, whidi is typically a graphical 
user interface running at a store ihanager's local personal 
computer. These interactions include interactions with 1) the 
Incentive Subsystem 160 to create discount programs, 2) the 65 
Order Fulfillment subsystem to configure or monitor the 
ordering process, 3) the Observations Subsystem 168 to 



monitcr store sales data, and 4) the Participant Subsystem 
164 (owned by service provider) and Customer Account 
Subsystem 117 (owned by store) to collect customer usage 
data. Of these, Item 1, incentive creation, which relates 
mostly to pre-sales activity, is discussed here. 
Creating Incentives 

In overview, and as shown in FIG. 10, the Store Man- 
agement uses Store Management Dashboard 20 to interface 
with the Incentives Subsystem 160 to create Incentive 
Programs 250. 

Information specified in aeating an Incentive Program 
250 would include the name and description of the incentive, 
its starting and ending dates, its sponsor, and the price 
discount Incentive Programs 250 are created independently 
of actual shopping sessions, although they may also be 
created whUe customers are shopping in the store. 

Incentive Programs 250 might include: in-store (public) 
price discounts, coupon-based price discounts, point-based 
fr^uent buyea: discounts, or quantity discount cards. 

The function of these incentive programs 250 invention 
will first be described with reference to FIGS. 11 to 13 and 
in the context of in-store price discounts, which are the most 
common type of incentive. Thereafter the coupon-based 
price incentive wUl be discussed as an extension to the 
general framework established by the discussion of in-store 
price discounts. Frequent buyer discounts and quantity dis- 
count cards are discussed, 
(i) In-Store Price Discounts 

In-store price discounts are those where a customer need 
not present a coupon to obtain the price discount, and which 
is contingent only upon the customer being in the store while 
the incentive program is being offered. These are analogous 
to publicly advertised weekly sales in a physical store. 

Although in-store sales are couponless from the custom- 
er's perspective, it will be convenient, from the architec- 
ture's perspective, to think of in-store price discounts as 
resulting from coupons that are distributed to the customer 
upon entering the store. That is, the customer need not faring 
coupons, but is automatically entitled to die appropriate 
coupons for any in-store sales. The coupon is used to inform 
the customer of all in-store price discounts in effect on 
entering tfie electronic store-^alogous to handing a sales 
flyer to a customer entering a physical stcre. This will be 
explained in detail in the discussion of an actual shopping 
session below. The concept of a coupon for in-store price 
discounts is also usefiil because it establishes an incentive 
framework that can be used for true coupon-based price 
discounts (where the customer must present a coupon to 
receive the price discount), discussed below. 

In-store price discounts are embodied in Incentive Pro- 
grams 250 created by an Incentives Subsystem 160, as 
shown in FIG. 10. Each Incentive is expressed in a Pricing 
Rule of the form: 



11/25/2003, EAST version: 1.4.1 



5,710,887 

21 22 

contains **20,** $20 will be deducted from the value indicated 
iB Pricing Database 116. 



struct BV._pricipgRuic ( Adjustment 2<ii2 is of type 'Tcrcentage," the amount 

long applicati on o cnmt'. . * . 

bo3cMrvalkL_witlL_otos; contains a value, expressed as a percentage, that is to 

BV_jVcyu5tmentAiidPredjcate lufe; s be deducted from the price indicated in Product Database 

); 116, For example, if the anwunt field contains ^'ZO," then the 

value indicated in Pricing Database 116 will be reduced by 
where applicatioD_count is the number of times the dis- percent 
count may be appKed; (b) Predicate Segments 

valid_with_others is TRUE if the incentive can be implied lO A Predicate Segment 264 is a specified condition an item 
to items abready subject to a pdang change and FALSE niust meet to qualify for the adjustment 
otherwise; and rule contains the Adjustment and Predicates Predicate Segm^t 264 also contains at least two fields, 
associated with the incentive: respectively a type field that indicates the type of test that is 

used to determine whether the pricing rule may be applied 
' 15 to a given item at a given time, and a conditions field that the 

struct BV_^ustincniflndPr«iicatc ( conditions that must bc satisfied in order for the pricing rule 

BV_JV(UU6tiiKnt adjustiDcnt; * i. i- j * c» 

BV_PredicatcList piedkates; ^O be apphed. 

); If Predicate 264 is of type *Time of Day," the conditions 

field contains two values, which indicate the beginning time 



EachPridngRuleisembodiedinaPridngRuleStiucture ^ of day and the end time of day that de^^ 

260, mustrat^ in HG. 11. Pricing Rule Structure 260 on which the i^cmgnUe may be apphed. For example^^ 

typically comprises three data se^nents. Tliese arc an conditions fidd contams Ae hvo va^ues^o^^^^ to 

Adjustiient Segment 262, a PredicaleSegment 264, and a tmies of day *a7:(K):00"and^^ 1:00:00," toe pncmg rule will 

Qualifier Segment 266, Each Pricing Rule Structure 260 be appUed only between 5:00 P^. and 9:00 P.M. 

includes one Adjustment Segment 262 and at least one of a 25 If Predicate 264 is of type "Date," die conditions field 

Predicate Segment 264 and/or a Qualifier Segment 266. contains two values, which indicate the beginning and end 

Each is discussed in detail below: dates on which the pricing rule may be applied. For exan^le, 

(a) Adjustment Segments if the conditions fidd contains the two values ooiresponding 

An Adjustment Segment 262 describes how the price of to the dates "Jul. 1, 1996" and "JuL 31, 1996," then the 

an item is affected if all Predicates Segments 264 (described 30 pricing rule will be s^lied only during the month of July 

below) are matched. The Adjustment 262 may be eitiier a 1996. 

sin:q)le adjustment or a quantity adjustment A sinq)le adjust- If Predicate 264 is of type "Day," the conditions field 

ment may either be fixed (e.g., sale price is $10), absolute includes a seven-entry boolean array, each entry of which 

(e.g., $10 off), or percentage (e.g., 10% off). A quantity corresponds to a particular day of the week. A "1" value in 

adjustment includes the price-based discounting of a simple 35 an entry indicates that the prichig nile may be applied on the 

adjustment but also allows for quantity-based discounting. It day to which the entry corresponds; a "0" value indicates 

takes the form: that the pricing rule is not to be applied on that day. For 

example, if the conditions field contains the value 

— — ^— "0000011," then the pddng rule will be applied only on 

" ^ 40 Saturdays and Sundays, 
unstsned sncrt required; 

unsigned shoit discounted; if Predicate 264 is of type Item Identifier, the conditions 

BV_SuiipieAdjiistment adjusting fidd contains a list containing one or more values that 

boolean iess_oi_equal; identify one OT more items to which the pricing rule may be 

^* applied. For exanq>le, if the conditions field contains the 

45 value **XQ>- 100-56," the pricing rule will bc applied only 

where required is the minimum purchase requirement, dis- to purdiases of tiie item identified in Product Database 116 

counted is the number of items discounted by this rule, as "XCD- 100-56." 

adjustment is the sinqile adjustment, and less_or_equal= Predicate 264 is of type "Item Attribute," the conditions 

TRUE if the discounted items must be less or equal in value field contains a list containing one or more values that 

to the items making up the minimum purchase requirement 30 identify an attribute of one or more items to which the 

Thus, Adjustment Segment 262 contains at least two pricing rule may be applied. For example, if the conditions 

fields, which respectively indicate the type and amount of field contains the value "blouse," then the pricing rule will 

adjustment to be made to a price of an item. An Adjustment be applied to all items identified in Product Database 116 as 

262 may be of a type None, Fixed, Absolute, or Percentage. having the attribute "blouse." 

The use of the amount field is dependent on the value of the 55 If Predicate 264 is of type "Mce," the conditions field 

type field. If Adjustment 262 is of type ^'None," no adjust- contains a comparator indicator having a value such as 

ment will be made to the price of an item at time of purchase: "greato- than," "less than," etc , and a comparison value to 

the item will be sold at the price indicated in Produa be con^ared to the item's price. For example, if the condi- 

Database 116. tions field contains a comparator value of "greater than" and 

If Adjustment 262 is of type **Fixed," the amount field 60 a comparison value of "10," the pricing rule will be applied 

contains a value to be substituted for the price indicated in to all items identified in the Product Database 116 as having 

I^oduct Database 116. For exan^le, if the amount field a price greater than $10. ^ 

contains **20," the price of the item will be $20, regardless (c) Qualifier Segments 

of the value in Product Database 116. Qualifier Segment 266 is used to identify additional 

If Adjustment 262 is of type "Absolute," the amount field 65 discounts that may be ^lied other than on an item-by-item 

contains a value to be deducted from the price indicated in basis. For example, a Qualifier Segment 266 may be used to 

I^oduct Database 116. For example, if the amount field ittdicatethatthepricingruleistobefq)p]iedonlyif 5 ormore 
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items are purdiased, if the transaction is for over $100 worth FIG. 12A depicts one view presented by the Dashboard 

of items, or to indicate that one product may be obtained at Client to storefront management. SpedficaUy, FIG. 12A 

no charge with the purchase of a particular second product depicts a storefront manager establishing an Adjustment 262 

(ii) Coupon-Based Price Discounts of type '^Percentage " indicating a 20% discount Dashboard 

In contrast to the Price discounts described above, 5 Client 280 displays a Pricing Term D^ails Window 282. 
coupon-based price discounts are those where a oistomer Pricing Term Details Window 282 includes a set of buttons 
must present a coupon in order to obtain a specified price 284 that are used to select the type of Adjustment 262 being 
discount in a present shopping session. Coupons may come defined, and a set of input areas 286 that are used to specify 
fi-om previous shopping sessions in the coupon-accepting the amount of discount to be applied, 
stoie (intra-store marketing), or from previous shopping lO FIG. 12B depicts a second view presented by the Dash- 
sessions in other stores or from a manufacturer supplying board Client 280 to a storefront manager. Specifically, FIG. 
many stores (inter-stcre marketing). 12B depicts a storefront operator establishing a Predicate 

The same incentive creation mechanism discussed above 264 of type "Date" that is valid firom Jul. 1, 1996 until Jul. 

for in-store price discounts is used to create coupon-based 31, 1996, and a Predicate 264 of type "Day" that is valid 

price discounts, which may be treated as a supers^ of 15 only on Saturday and Sunday. Dashboard Client 280 dis- 

in-store price discounts. The primary difference is that the plays Sales Details Wndow 288. Sales Details Window 288 

fields for total numbers of coupons and starting serial includes a set of two input areas 290 to specify the beginning 

number arc now significant, for they are tools by which store and end dates on which this pricing rule may be applied, and 

management can limit coupon offerings and track coupon a set of Day-of-the-Week buttons 292 that indicate the days 

redciiq)tions. 20 on which the pricing rule may be applied. 

Specifically, coupons otfier than in-store sale coupons are Referring now to FIGS. 12, 12A and 12B together, at the 
persistently retained in Participant Program Object 112 from control of the storefront manager and responsive to the data 
session to session, rather than being available only in the input by the storefront manager, Dashboard Client 280 
particular session and storefront in which the coupons were creates Pricing Rule Structure 300. Thereafter, Dashboard 
distributed. A coupon contains the same information as 25 Client 280 calls Incentive Factory 302, passing it Pricing 
in-store sale coupons as depicted, namely, the applicable Rule Structure 300. Incentive Factoy 302 creates Incentive 
Adjustment Segments 262, Predicate Segments 264, and Program Object 160 reflecting tiie contents of Pricing Rule 
Qualifier Segments 266. In addition, such coupons also Structure 300. Dashboard Client 280 then calls Distributor 
contain a serial number and a digital signature. The serial Factory 304, passing it as a parameter Incentive Program 
number is an arbitraiily-sized numeric field that is unique for 30 Object 160. Distributor Factory 304 creates EHstributor 
every coupon distributed by a Distributor Object, within a Program Object 118. As described before, Distributor Pro- 
range as specified at the time the Incentive Program that gram Object 118 will be made available to Storefronts 14, 
produced the coupon was created. When a coupon is and will provide Storefronts 14 with Coupons 119 at trans- 
redeemed, an entry for that coupon is made in Redemption action time. 

Database 172, indicating that the specific coupon with the 35 Dashboard Client 280 then calls Redemption Registry 

specific serial number has been redeemed. A coupon with a 310, passing to it as a parameter Incentive Program Object 

given serial number will only be redeemed if the Redemp- 160. Redemption Registry 310 records Incentive Program 

tion Database does not contaia an indicatCK- that the coupon Object 160 in Redemption Database 170. As will be recalled 

has already been redeemed. This prevents a coupon from and as described with reference to FIG. 7, Redemption 

being copied and used by more than one customer, and from 40 Database 170 will be used by Sales Representative Program 

being reused by the same customer more than one time. Object 114 to validate any Coupons 119 sought to be applied 

To maintain the integrity of the coupon's contents, the to a transaction, 

coupon also contains a digital signature. The digital signa- FIG. 13 d^icts the operation of Pricing Engine 120 in 

ture is a field whose content is the result of a cryptogr^hic applying Coupons 119. In Step 300, Pricing Engine 120 

(^ration using, for example, the public key encryption 45 begins jffocessing the Purchase list 170 and the associated 

metiiod of RSA Data Security, Inc.. The cryptographic Coupons 119. 

operation operates on the contents of the remainder of the In Step 304, Pricing Engine 120 diecks whether it has 

coupon, using a key to yield a digital signature, which is been passed any Coupons 119. If there are no Coupons 119 

stored in the coupon. With the digital signature, any modi- to be applied. Pricing Engine 120 skq)s processing of 
fication of the coupon will fail the redemption process when 50 incentives and proceeds to Step 306. 

the digital signature is compared to the remainder of the But, should any Coupons 119 apply, and as shown in Step 

coupon. This prevents, for exan^)lc, a customer from alter- 308, Pricing Engine 120 selects the first of the Coupons 119 

ing a discount field to obtain a discount that is greater than for processing. In Step 310, Mcing Engine 120 selects the 

. that offered by the storefront. It also prevents a customer first of the R-edicate Segments 67 in the Coupon selected. In 
from making a copy of a coupon and changing its serial 55 Step 312, Pricing Engine 120 evaluates the selected Predi- 

numbo' so that it can be used in addition to the original cate Segment 264 to see if it applies to any of the products 

coupon. specified in Purchase List 170. In Step 314, if conditions 

Dashboard Operation specified in the Predicate Segment 264 are not met. Pricing 

As indicated above. Store Management interacts with tiie Engiue 120 skips to Step 316 without ^plying the incentive, 
system through a Dashboard 20» typically hardware with an 60 If the conditions specified in the Predicate Segment 264 are 

associated display screen. Associated wltii Dashboard 20 met, Mcing Engine 120 in Step 318 checks whether there 

and as shown in FIG. 12, is a Dashboard Client 280, In the are further Predicates to be tested. If so, Pricing Engine 120 

form of software. As illustrated in FIGS. 12A and 12B the in Step 320 selects tiie next Predicate Segment to be tested. 

Dashboard Client 280 causes certain infomoation to be and repeats from Step 312. 

displayed on the screen of tiic Dashboard 20. In OTder to 65 If all Predicates have been satisfied, in Step 322, Pricing 

better understand the operation of the Dashboard Client, Engine 120 ^lies the Coupon's Adjustment Segment 262 

these three Figures should be referenced together. to the price of the item as obtained from Product Database 
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116, i.e., by ai^lybg a new price for this transaction (for an General system navigation events may include, for 

Adjustment of 'Tixed"), by reducing the price by the example: Start-Session, End_Session, Generic_J*rofile, 

dollar amount indicated (for an Adjustment of type Enter_Service, Exit_Service, Enter_Categary, Exit_ 

"Absolute"), or by reducing the price by tiie percentage Category, Enter_JLocatioD and Exit__Location. 

indicated (for an Adjustment of type •Tercentage"); 5 jhe Start_JSession event defines when a customer begins 

In Step 316, Pricing Engine 120 checks whether there are ^ particular commerce session, This may be, for example, 

further Coupons 119 to be Foccssed. If more Coupons U9 ^hen the customer logs on to Conq)uscxve, America Online, 

remain to be processed, Mang Engme 120 m Step 324 ^^^^^ ^^y^^^^ following data: session^d, an 

selects &e next Coupon to be pro(^^ unique identifier identifying the session; session 

aiOtobe^processmgofthen^^^^ connection, which identifies how the customer is connecte'd 
to Incentive Prop^ ObjKtha^^^ fticing 

Engme 120 p-oceeds to Step 326. In Step 326, Rncmg ouu u«ic_uji«;, a uuuwujuc auuut;. mc 

En^e 120 cLputesthetoScostofthetonsaction, with End^^ion event defines when a customer exits a par- 

aU Coupons 119aw>Ued to Purchase Ust 170. In Step 328, ?«sion- This event mdudes the date: session_jd and 

Pricing Engine 120 returns control to Sales Representative date„time. 

Program Object 114. Gcneric_Profile event is optionally generated at 

Observation Subsystem session start time to provide the Observation Subsystem 

The Observations Subsystem 168 (HG. 5) provides a with information regarding the customer. This event 

system for recording events that rqa-escnt observable data includes the following data; incorae_Jevel; gender; age; and 

that results firom customer interactions. FIGS. 14 and 15 geogr^hic location. 

depict the Observation Subsystem 168. Observation Sub- 20 The Enter_Service event is generated when a customer 

. system 168 conqirises two types of program object. These begins using a particular storefront This event includes tite 

are called collectors and event recipients. FIGS. 14 and 15 following data: sesslon^d; sexvice_Jd, which identifies the 

depict three coUectOTS 340, 342 and 344 and four event particular storefront in use by the customer, and date_Jirae. 

recipients 350, 352, 354 and 356. A program object called a a corresponding ExiUlervice event is generated when the 

"collector" communicates events to one or more event 25 customer leaves the stcarefront, and includes session_Jd; 

recipients that have registered with the collector. Event service_Jd, and date__time. 

RedpienU arc of two types, either Active Monitors ot The Enter_CategOTy event is generated when a customer 

LoggHS. , . r t_ selects a particular category of items to review within a 

Active MonUorsperfonared-tm^ storefront It includes the foUowing data: session^d; 

tions. Each Active Momtor analyses ccrtam types of data to „ ^^^v*. iA. a^*^ oot^«««, w ;H*nhfiAc 

producearesultthatcanbedisplayedtoastoi^pcratorvia '° f^^"!;^^; ^ V ' ^^^"^^ 

Se Dashboard. An example is an Active Momtor to moni- P^<=^ f ^^^^^^ ^ ^\TT'''J' 

toring sales volrnxwrSuXan Active Monitor could receive conespondmg Exit_Category event is ^ncrated when the 

events that describe orders purchased, and calculate a peri- customer exits tiie category and mcludes session_id; 

odic total of items being purchased. TTie result would be a servicc_ad; date_tunc; and categOTy_Jd. 

tracking of volume of orders on aperiodic basis, e.g., hourly. 35 The Entcr_jLocation event is generated to identify physi- 

which could be presented as a gr^hical display on the cal location infonnation about items being reviewed by a 

Dashboard. customer, for example, a particular spot on a printed catalog 

Loggers receive observations and write them to an exter- being reviewed by a customer. It includes the following data: 

nal file in a predefined format, to produce a log of events that session_Jd; service^d; date_time; and location_id, which 

can be subsequently processed for historical, analysis. For 40 may, for exan^le, identify the cartesian coordinates within 

example, the log could be processed to determine if there is a particular catalog p^e being reviewed by tite customs. A 

a trend signifying an increase over time of purchase of corresponding Exit_l.ocation is generated when the cus- 

selected items. Also, purchases over time may be correlated tomer stops reviewing the physical location and includes the 

with specific attributes of customers, e.g., income level or following data: sessioa_id; service_Jd; date_time; and 

neighborhood. The resulting information could be provided 45 locatioii_Jd. 

to the Promotions Subsystem 116 to durect particular pro- Shopping events may include, for exanml^|| ^ecU uRea^ 

motions to customers having similar attributes. 4ltaii^|ij|gHMaid >%pi0S9^^ 

FIG. 14 depicts the process of registration with a collec- The Select_Jtem event is generated when a customer 

tor An Event Recipient sudi as Event Recipient 350 locates selects an item as a purchase candidate, akin to when a 

a Collector such as Collector 340 by means of a nameserver so customer in a real store places an item in a shopping cart 

such as that specified by the CORBA Object Request Broker The Selectjtem event includes the following data: 

specification. Event Recipient 350 makes a call 360 to session_Jd; service__id; date_time; and producCJd, which 

Cdlectpr 340, requesting to be registered with CollecttH: identifies the selected product. 

340. FIG. 14 depicts Event Recq)ient 350 registering with The Unselectjlem event is generated when a customer 

Collector 340; Event Recipient 352 registering with Collect ss decides not to purchase a particular item and unselects the 

tors 346 and 342; Event 354 registering with Collector 344; item as a purchase candidate, akin to removing it from the 

and Event Recipient 356 rcgistering with Collector 342, As shopping cait and replacing it on the store shelf. The 

can be seen in FIG. 14, an Event Rec^ient may be registered Unsdect_Jtem event includes the following data: session^ 

with more than one Collector, and a Collector may register id; scrvicc_Jd; date_time; and product_id. 

more than one Event Recipient 60 The \lew_Jtem event is generated when a customer 

FIG. 15 depicts the process of communicating Events 361 requests derailed information about an item being offered by 

from Collectors 340, 342, and 344 to Event Recipients 350, a storefront The View_Jftcm event includes the following 

352, 354 and 356. Each Collector communicates events only data: session_id; servioe_Jd; date_time; and product_id. 

to the Event Recipients that have registered with it Purchasing events may include, for exanqde: Purchase_ 

Events that arc transmitted by a collector may include 65 Item and Purchase__Qrder. 

events tracking general system navigation events, shopping The Purchase_Jtem event is generated when a customer 

events, purchasing events, and user-defined events. actually purchases a selected item. When a purdiase rcquest 
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is made, one Purdiase_Jtcm event is generated for each IL Coupon-Based Frequent Buyer Points 

item purchased. The Purchase_Item event includes the A coupon-based pice frequent buyer program is one in 

following data: session_id; service_id; date_time; which the customer presents a coi^n, typically from a 

product_id; retailjrice; discount_price; and incentive^ previous shopping session, for frequent buyer points in a 

name, which identifies any incentive that was applied to the 5 present shopping session. The frequent buyer coupon takes 

price. the same pvedicate^adjustment fonn as the price discount 

The Purchase_Qrdex even is generated when a customo- coupon, except that the adjustment takes the form of points 

actually makes a purchase of one or more items. When a issued to a customer's frequent buyer account rather than an 

purchase request is niade, one Purchase_Order event is instantaneous price discount. Tlie customer may redeem 

generated fac the entire <xda, regardless of the number of ^ ^^^^ ^^^^^ discounts, 

items in the order. The Puichase_Order event includes the ^Q^^^ty Discount Incentives 

following data: session id; service_id; date t^e; Athirdtypeof incentive program is the quantity discount 

number of^temsjurchased; total_pnce; and totaU HereX customer hafa fuantlty disLnt card whic^ 

TuL-DefinedEventisageneral-purposeeventthatmay ^ clectronicaUy punc^ each time the customer makes a 

be generated for any event tl^t is of Kst to the operator ^5 qualifying purdiase When a required numb^ of punches 

of Ae commerce system. The User_Defined event includes have been made, the customer receives a discount, e.g., 

the following data: session^d; servicc_Jd; datc_time; "Buy 10, Get 1 Free* or $10 off. 

user_defined_type, which is a user-defined field that iden- CONCLUSION 
tifies the type of user-defined event being observed; and 

data_string, a string of data formatted according to the 20 In summary, the electronic mall is an example of a system 

needs of the developer. architecture in whidi interface-con^liant implementations 

Vn Additional Features of tiiese basic functional subsystems may be interconnected 

Variations on Above Disclosed Embodiment in a manner to suit the needs of a particular electronic 

a. Long-lived Sales Representative commerce participant The invention provides some sub- 
In the previously described embodiment of the invention, 25 systems directly (in the fonn of complete Internal Com- 

the Customer Monitoring Object/Sales Representative Pro- merce Subsystems), and other subsystems indirectly (in the 

gram Object 114 was created and tenninated after each form of interfaces to External Commerce Subsystems), with 

shopping trip. In another embodiment of the invention, a each store being able to select the particular combination 

Sales Representative Program Object 114 may be longer- that best suits its specific needs. However, all subsystems, 

lived. Typically, Sales Representative Program Object ter- 30 whether External or Internal, are compatible with a set of 

mination is associated with customer billing. For exanqde, if standardized subsystem interfaces. At the front end, a cus- 

the Electronic Storefront uses monthly rather than session tomer shops in the electronic store through an Electronic 

billing, the Sales Reiwcsentative Program Object 114 would Storefront, and at the back end, the store management 

be terminated at the end of the monthly shopping cycle interfaces with and controls the various subsystems through 

rather than at the end of each shopping trip. 35 a Store Management Dashboard. 

In cases where a customer's Sales Representative Pro- xhe operation of the system described above includes 

gram Object outlives the shopping trip during which the exemplary code for selected interfaces where it is illustrative 

Sales Representative Program Object was created, termina- of the operation of the subsystem. The source code is written 

tion of a shopping trip causes the Sales Representative using the Common Object Request Broker Architecture 

Program Object to become "dormant." TVpically, this is 40 (CORBA) Interface Definition Language (IDL). 

effected by causing information regarding that shopping trip publications and existing subsystems noentioned in 

to be stored and, for example, flags^winters to be set so that specification arc herein incorporated by reference to the 

the Sales Representative Program Object can be **revived" ^^^^^ ^ individual publication or existing 

or rccaUed at a later date. Subsequent shopping Rips can subsystems were specifically and individually indicated to 

then be initiated by recalling the particular Sales Represen- 45 be incorporated by reference. 

Utivc Program Object assigned to that aistom^. TTjereafter jt ^ai be apparent to one of ordinary skill in the art that 

the transaction would proce^ as m the e^fflier-desmbed changes and modifications can be made thereto with- 

• embodiment except that the Sales Re^presenla^^^ ^ ^ ^ 

Object would only be terminated at the end of the shoppmg claims ^ 

trip if customer billing was performed. 50 chho: 

b. Sales Representative Program Object for Multiple Stores ^ ^ faciHtating commercial transactions, 
Similarly, the above description focuses on a Sales Rjsp- ^^^^^^ a plurality of customers and at least one supplier of 

r^ntative Program Object assoaated with a sm^e suK>Uer ^^^^ ^ ^^^^ ^^^^^^ ^ 

of Items such as a store, IS, however, possflbleth^^ comi^unications between the supplier and at least one 

Reprcscntaivc Program Object can be created to attend to 55 ^.^^tomcr site associated with eadi customer and including 

a customer interacting with a number of supph^. to this ^ ^ ^ comprising: 

embodiment, the Sales Representative Program Object can ^ ^ - \y ^ 1*1. 

^ntain a H^t of aU items selected by the Sma as weU ^ for causmg at least one suppherl^o b^ 

Ta reference to the supplier of each item. sented on the display for selection by the customer 

c Frequent Buyer InceSves 60 usmg the i^ut means; 

L In-store Frequent Buyer Pointe b. means for effecting iwsentation of items on the display 

Another type of in-store incentive is a frequent buya ^ customer observation; 

points program. Here, the in-store incentive takes the form c an item database associated with a supplier and indud- 

of points issued to a customer's frequent buyer account Ing information on presented items; 
rather than an instantaneous price discount The customer 65 d. pricing means for receiving information frona the item 

may redeem points at various levels to obtain actual price database to determine the cost associated with a pre- 

discounts. sented item; 
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e. a customs iufonnation database for stoiiiig informa- 
tion relating to a customer; and 

f. means for creating a customer monit<xing object for 
each customer by referencing information, relating to 
that customer, which had been stored in the customer 
information database and upon the customer selecting 
at least one suj^lier such that the customer monitoring 
object is configured to operate by 

i. responding to customer enquiries, communicated 
through the input means, regarding a presented item 
by accessing the item database to retrieve informa- 
tion relating to said item and to present said infc^- 
mation to the customer by means of the display, 

ii receiving a customer's selection of a presented item 
through the input means, 

iii. communicating with the pricing means to have the 
cost of the item determined, 

iv. presenting the cost to the customer by means of tiie 
display, 

v. receiving customer communications, through the 
input means, indicating a desire to receive the item, 
and 

vi. passing a delivery initiation commmiication to ini- 
tiate the delivery of the item to the customer. 

2. The system of claim 1, further comprising a customer 
monitoring object configured to operate by: 

a. responding to customer enquiries, communicated 
through the input means, regarding a presented item by 
accessing the item database to retrieve inf<^mation 
relating to said item and to present said information to 
the customer by means of the display, 

b. receiving a customer's selection of a presented item 
through the input means, 

c. CQmmunicating with the pricing means to have the cost 
of the item determined, 

d. presenting the cost to the customer by means of the 
display, 

e. receiving customer coimnunications, througih the input 
ineans, indicating a desire to receive Ae item, 

f. passing a delivery initiation communication to initiate 
the delivery of the item to the customor, and 

g. maintaining a list of selected items and present the 
customer with a cost of the selected items for approval 
by the customer before the customer monitoring object 
passes the delivery initiation communication. 

3. The system of claim 2, wherein the customer monitor- 
ing object is configured to present the customer with an 
oppcftunity to deselect an item whereupon the customer 
monitoring object communicates with the pricing means to 
have the costs of the remaining selected items redetermined 
and presented anew to the customer. 

4. The system of daim 2, further conqirising order ful- 
fillment initiation means, responsive to the delivery initia- 
tion communication from the customer monitoring object, 
for initiating proceedings to cause the item desired by the 
customer delivered to the customer. 

5. The system of daim 4, wherein the order fulfillment 
means indudes an interface with a shipping fadlity for 
facilitating the shying of the desired item to the customer. 

6. The system of claim 2, further comprising a payment 
handler means for initiating customer payment for the 
desired item. 

7. The system of daim 6, wherein the payment handler 
means is responsive to communications from the customer 
monitoring object and receives information from the cus- 
tomer identification database in order to initiate customer 
payment 
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8. The system of daim 7, wherein the aistomcr monitor- 
ing object is configured to confirm to the customer that the 
order for the item has been successfully processed. 

9. The syst^ of daim 2, further comprising a payment 
5 validation system induding 

means for causing the customer monitoring object to 
receive the inf onnation related to the f oms of payment 
available to die customer and to present the customer 
with a sdecdon of the forms of payment; 

io means for recdving a first security code, rdated to a 
sdected form of payment, firom the customer, and 
means for validating the first security code by comparison 
to a second security code available to the customer 
monitoring c^joct; 

j3 whereby payment for the item is initiated if die first 
security code is validated. 

10. The system of daim 2, further cQnq)rising a cost 
discount storage for maintaining cost reduction information 
associated with a supplier's items, 

whadn the pricing means receives relevant parts of the 
cost reduction information to calculate the cost of the 
assodated item 

11. Hie system of daim 10, wherein the customer moni- 
toring object is configured to receive cost reduction infor- 
mation communicate the reduction information to the pdc- 

25 ing means. 

12. The system of daim 11, wherein the customer moni- 
toring object is ooiifigured to confirm to the customer that 
the order for the item has been successfully processed. 

13. The system of claim 12, wherein the supplier control 
30 means is configured to receive input, from a supplier at a first 

time, to define changes to the cost reduction information for 
a second time later than the first time. 

14. The system of daim U, further comprising supplier 
control means for receiving input, firom a suppUer, for 

35 changing the cost reduction information. 

15. The system of daim 2, further comprising means, 
responsive to an input firom the customer, to terminate the 
customer's interaction with the supplier whereupon which 
termination the customer monitoring object ceases to oper- 

40 ate. 

16. The system of daim 2, further conqnising means, 
responsive to an input from the customer, to tenmnate the 
customer's interaction with the supplier whereiq)on the 
customer monitoring object ceases to opemte and ioforma- 

45 tion regarding at least the interaction is stored for retrieval 
at a subsequent time at which the customer interacts wifli the 
supplier whereby the customer monitoring object recom- 
mences operation utilizing tiie stored information. 

17. The system of daim 16, wherein the partidpant 
50 program object indudes information related to forms of 

payment available to the customer. 

18. The system of claim 2, further comprising means for 
accessing the customer information database and for creat- 
ing a partidpant program object induding information spe- 

55 dfic to the customer retrieved firom the information database 
and in communication with and for passing customer spe- 
cific information the customer monitoring object. 

19. The system of daim 18, wherein the partidpant 
program object is created at the time an interaction between 

60 the customer and the system commences. 

20. The system of claim 2, further comprising an obser- 
vation subsystem for receiving and maintaining customer 
interaction information relating to at least one customer's 
communications over the conqniter driven network. 

65 21. The system of daim 20, further comprising supplier 
control means for recdving input, from a supplier, for 
changing the cost reduction infoimatton. 
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22. The system of claim 21, wherein the supplier control 
means is coDiig;ured to receive input, from a supplier at a first 
time, to define changes to the cost reduction infomiation for 
a second time later than the first time. 

23. The system of claim 22 wherein the supplier control 
means is in communication with die observation subsystem 
to receive customer interaction information for display to the 
supplier. 

24. The system of daim 23, wherein the supplier control 
includes: 

a. an infonnation processor for processing received cus- 
tomer interaction information; and 

b, means for selectively displaying at least a part of the 
processed customer interaction information to the sup- 
plier. 

25. The system of claim 2 wherein the means for causing 
at least one supplier to be represented can cause a plurality 
of suppliers to be rqjresented, the system further comprising 
means to enable a customer to select at least one of the 
represented suppliers. 

26. A system for facilitating commercial transactions, 
between a plurality of customers and at least one supplier of 
items, over a computer driven network capable of fsoviding 
communications between the supplier and at least one 
customer site associated with each customer and including 
an input means and a display, the system conqirising: 

a. means for causing at least one supplier to be repre- 
sented on the display for selection by the customer 
using the input means; 

b. means for effecting presentation of items on the display 
fca: customer observation; 

c. an item database associated with a supplier and includ- 
ing information on presented items; 

d. pricing means for receiving infonnation firom the item 
database to determine the cost associated with a pre- 
sented item; 

e. a customer information database for storing informa- 
tion relating to a customer; and 

f. means for creating a customer monitoring object for 
each customer by referencing infomiation, relating to 
that customer, which had been stored in the customer 
infonnation database and upon the customer selecting 
at least one supplier such that the aistomer monitoring 
object is configured to operate by 

i. responding to customer enquiries, communicated 
through the input means, regarding a presented item 
by accessing the item database to retrieve informa- 
tion relating to said item and to present said infor- 
mation to the customer by means of the display, 

ii receiving a customer's selection of a presented item 
through the input means, 

iii. communicating with the pricing means to have the 
cost of the item determined, 

iv. presenting the cost to the customer by means of the 
display, 

v. receiving customer communications, through the 
input means, indicating a desire to receive the item, 

vi. passing a delivery initiation communication to ini- 
tiate the delivery of the item to the customer; and 

g. a means for accessing the customer infonnation data- 
base and for creating a participant program object 
including information specific to the customer retrieved 
from the information database and in conununication 
with and for passing custonoier specific information to 
the customer monitoring object 

27. The system of claim 26, further con^sing a customer 
monitoring object configured to operate by: 
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a. responding to customer enquiries, communicated 
through the input means, regarding a presented item by 
accessing the item database to retrieve information 
relating to said item and to present said information to 
the customer by means of the display, 

b. receiving a customer's selection of a presented item 
through the input means, 

c. communicating with the pricing means to have the cost 
of the item determined, 

d. presenting the cost to the customer by means of the 
display, 

e. receiving customer communications, through the input 
means, indicating a desire to receive the item, 

f. passing a delivery initiation communication to initiate 
the delivery of the item to the customer, and 

g. maintainin g a list of selected items and present the 
customer with a cost of the selected items for approval 
by the customer before the customer monitoring object 
passes the delivery initiation communication. 

28. The system of claim 27, whffcin the customer moni- 
toring object is configured to present the customer with an 
opportunity to deselect an item whereupon the customer 
monitoring object communicates with the jsicing means to 
have the costs of the renaming selected items redetermined 
and presented anew to the customer. 

29. The system of daim 27, further comprising order 
fulfillment initiation means, responsive to the delivery ini- 
tiation communication from the customer monitoring object, 
for initiating proceedings to cause the item desired by the 
customer delivered to the customer. 

30. The system of daim 27, wherein the order fulfillment 
means indudes an interface with a shq)ping facility for 
facilitating the shipping of the desired item to the customer. 

31. The system of claim 27, further comprising a payment 
handler means for initiating customer payment for the 
desired item. 

3Z The system of daim 31, wherein the payment handler 
means is responsive to communications from the customer 
monitoring object and receives information from the cus- 
tomer identification database in order to initiate customer 
payment 

33. The system of daim 27, further comprising a payment 
validation system including 

means for causing the customer monitoring object to 
receive the information related to the forms of payment 
available to the customer and to present the customer 
with a sdection of the forms of payment; 

means for recdving a first security code, rdated to a 
sdected form of payment, from the customer; and 

means for validating the first security code by comparison 
to a second security code available to the customer 
monitoring object; 

whereby payment for the item is initiated if the first 
security code is validated. 

34. The system of claim 27, furtho- comprising a cost 
discount storage for maintaining cost reduction infcraation 
assodated with a supplier's items, 

wherein the pricing means receives relevant parts of the 
cost reduction information to calculate the cost of the 
associated item. 

35. The system of daim 34, wherein the customer moni- 
toring object is configured to receive cost reduction infor- 
mation communicate the reduction infomiation to the pric- 
ing means. 

36. The system of daim 35, further comprising means for 
receiving input, from a supplier, for changing the cost 
reduction information. 
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37. The system of claim 36, wherein the supplier control 44. The system of daim 27, further comprising an obser- 
means is configured to receive input, from a supplier at a first vation subsystem for receiving and maintaining customer 
time, to define changes to the cost reduction information for interaction information relating to at least one customer's 
a second time later than the first time. communications over the counter driven n^work. 

38. The system of claim 27, further comprising means, 3 45, fhe system of claim 44, further con^irising si^plier 
responsive to an input fix)m the customer, to tenninate the control means for receiving input, from a supplier, for 
customa-*s interaction with tiie suppUer upon which termi- changing the cost reduction information. 

nation the customer monitoring object ceases to qperate. ^ -j^e system of claim 45, whffein the sillier control 

39. The system of cl^ 27, further comprising means, means is configured to receive input, from a supplier at a first 
responsive to an mput from the custonaa, to terminate 10 tiioe, to define changes to the cost reduction information for 
customer's interaction with the suppher whereupon tiie ^ ^^^^ ^ hiUr thm the first time. 

aistomer monitoring object ceas^ to pP«ate and mforma- ^ ^ ^^^^ 

tion regardmg at least the mteraction is stored for retneval . . ' . ^, L. ^* . T . ^ 

^ ^ J- *. • * *i- means is m commumcation with the observation subsystem 

at a subsequent tune at which the customer mtaacts with the " ^luuiumwiixwLi wxui wow t*"^*^ ^ uoj^oiwu 

1- \ 4U ♦ •«« ^ui^^ ic to receive customer mteraction infcffmation for display to the 

suppUer whereby the aistomer monitormg object recom- is . *^ ' 

moiccs opttation utilizing the stored information. ™ . r 1 • u • v *->.i 

^ * 1 ^ ♦k- 48. Tlie system of daim 47, who-ein the smmliCT control 

40. The system of claim 27, wherem the participant • 1 h . 
program object is created at the time an interaction between ineans m u s: 

tiie customer and the system commences. a. an information processor for frocessing received ccs- 

41. The system of daim 40, wherein the participant 20 tan^^r interaction information; and 

program object indudes information related to forms of b. means for sdectivdy displaying at least a part of the 

payment available to the customer. processed customer interaction information to the sup- 

42. The system of daim 27, further conqirising means for plier. 

causing at least one supplier to be represented on the display 49. The system of daim 26 wherein the means for causing 

and means for receiving an input from tiic customer indi- 25 at least one supplier to be represented can cause a plurality 

eating a selection of a represented supplier. of suppliers to be represented, the system further con^sing 

43. The system of daim 42, whereby said means for means to enable a customer to select at least one of the 
creating a customer monitoring object creates the customer represented suppliers. 

monitoring object for the customer when the customer 

selects the supplier. ***** 
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